Subject: Call for comments on David McDonell's submission

From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
Date: Mon, 31 Oct 94 13:02:38 PST

Fellow Data Link Switchers -

Some time ago, David McDonell submitted an Email message to the
general AIW mailer and nobody responded to it.  Although
most of the comments were editorial, several of them dealt
with technical content and needed to be dealt with by the
appropriate RIGlets (Connect, Capabilities Exchange,
Priority, and Flow Control).

I am resubmitting the message to the group, with my comments.
My comments start with an Asterisk "*" in the first line.

In particular, If you are a RIGlet member (or have expertise
and would like to comment) please comment on the sections which
my comments say "Refer" "Will Refer" to XXXX Group, to
the appropriate RIGlet mailer (e.g. aiw-dlsw-connect for State
Machine or Protocol Flow diagram comments).

This submission was a good example from someone who read
the entire document, not just what changed between versions.
I would suggest that since we are coming up on trying to 
finish this document that all of you do the same when
reading Editor's version 0.15.

Thank you for your support,

Alan (your editor)

-- Begin Included (edited) message --

Louise/Alan et al,

As you may remember I am a (very) late-comer to the DLSw RIG (AIW6), but I
won't let that stop me from offering some (largely editorial) comments 
on version 014.  Apologies if I'm commenting on issues previously touched (I
realize I'm missed a LOT of history here), and feel free to ignore items that
miss the mark.  That aside, hopefully there is some value in a neophyte view 
of the document as unbiased from previous discourse.  

Here we go:

- there's a fair number of typos in the 014 version; I pointed out several 
to Alan in Raleigh and he said he was doing spell checking at that point, so
I won't bother listing them all here.

- I presume all the revision/change history gets dropped when the document
goes from Alan to Wayne; if not that section should be reformatted a tad
(indentation, spelling/grammar, etc).

* Revision History will be dropped after Version 0.15

- section 1 (Intro, 1st para, p7): the reference to "SNA and OSI layer 2" 
datalink (specifically the *OSI* reference) layers is a tad confusing in
reference to SDLC and 802.2.  

*Section 1 reworded for clarity.

- section 1 (Intro, 2nd para, p7): the mention of "PU2 and PU4" systems is 
a bit confusing; the qualification of SDLC only being supported to a PU2
device implies that the arch is limited to supporting SDLC *secondary* 
alone (my understanding is that it does not, although most implementations
do).  Also, "PU2" is (of course) technically exclusive of "T2.1" -- and the 
intro therefore excludes T2.1 APPN nodes from the statement...which is 
(correctly) contradicted by the T2.1 target station example on p.54.

* Added PU 2.1, primary or secondary PU 2, and reworded.

- section 2 (Overview, 2nd para, p.7): a major, valid point is made around 
the distinction between DLSw and source route bridging (802.2 having been
designed for LAN links alone), but the explanation qualifies 802.2 
specifically as LLC type *2*.  Further down (para. 4) you state that NB uses
LLC2 Type 1, but in that context it reads as though wan bridging timeouts
are *not* a problem for T1.  (Feature or bug?)

* Clarified text for type 2 versus type 1 differences.  NetBIOS UI frames
are also sometimes subject to delays, but this is not addressed by DLSw.
Decided to leave that text alone.

- section 3 (Transport Connection, 2nd para, p.9): there's a bit of ambiguity 
around reliable transport selection.  This paragraph (correctly) points out 
that TCP/IP is simply the first standard backbone protocol supported (citing
OSI TP4 as a potential alternative), however the very first intro paragraph 
(p.7) clearly states that the DLSw architecture only supports TCP/IP.

* Moved text from section 3 to section 1.

- section 3 (Transport Connection, 4th para, p.9): the sentence that reads:
"Within the transport connection is a specific set of DLSw SSP messages units"
strikes me a awkward.  A better syntax might be: "Within the transport
connection, a specific set of DLSw SSP message units are supported; the PDU
formats and types are documented in the following sections."

* Reworded both sentences.

- section 3.1 (SSP Frame Formats, top p.10): change "...show the two message
headers for traffic between Data Link Switches" to read "...show the two 
message header formats exchanged between Data Link Switches, Control and 
Information."  [just a little less ambiguous; avoid confusing msg *format* 
with specific *types*]

* Done

- second sentence of same section (p.10): change sentence to read "The Control 
message header format is used for all message types except Information 
(INFOFRAME) and Independent Flow Control (IFCM), which are sent in the
Information format.  [clarity]

* I had already edited that sentence at the AIW, added your words at the end.

- control/info message field descriptions (pp.11): the first 16 (decimal) bytes
of the control and information headers are identical, and yet the graphical
field descriptions are not precisely the same ("version number" vs. "version",
"reserved field" vs. "reserved", etc.)  Ditto for the picture as it relates
to the text underneath it (e.g. p.13): "Flow Control Byte" vs. "Flow Control
field', etc.  [a nit, to be sure, but could be a source of confusion to 
someone, somewhere]

* Made the two pictures the same, and changed
text to Flow Control Byte field.

- control/info message field descriptions (p.13): it's at first glance 
confusing to have what appears as the *control* header field breakdown follow 
the *informational* header picture; at first I that it was an ascii 
formatting glitch.  Maybe put an intro sentence here like "fields found in
both the control and information headers and the control header alone are
described as follows" -- or something to that effect.  It's also confusing to
have only a subset of the field documented (e.g. jumping from the message 
length field to the flow control field, p.13).

* Added an intro sentence to the descriptions.

- p.13 bottom paragraph: syntax that wouldn't be caught w/ spell checker:
"Only the first field be used...".   Also, the reference to the two distinct
message type fields would be clearly if it referenced the respective offsets
of *each* (14 and 23 decimal).

* Changed to "is to be used", and added offsets to sentence.

- section 3.2 (Address Parameters, p.14): the descriptions of the Data Link
ID, Circuit ID, and Transport ID relative to the pictorial breakdown of the 
corresponding fields in the header message formats is confusing.  Maybe relate 
the terms to the actual header fields, and explicitly qualify "data link id" 
and "circuit id" as having both an Origin and Target context (as is done with
"transport id")?  This should be done in the first few sentences of section 
3.2.  

* Added offset to control message in the diagram, and an introductory
sentence explaining "Origin" and "Target" as follows:
Each attachment address is classified as either "Target" in the context
of the Destination MAC/SAP addresses of an explorer frame sent in the
first frame used to establish a circuit, or "Origin" in the context of
the Source MAC/SAP addresses.

Also, last sentence 2nd para (between two field diagrams) reads: "...originated
the establishment of a circuit, the terms, origin DLSw and target DLSw, will
be employed..." should read "...originated the establishment of a circuit, the
terms _origin_ DLSw and _target_ DLSw will be employed..."

* Added quotes and Captialized the first letter of Origin and Target.

- general, p.15: I don't think the "*_cs" and "*_ex" naming convention is
explicitly explained (or footnoted).  Imho, it should be (forward reference
to section 3.5 message type table, where (I think) the "circuit start" and
"explorer" suffixes are used for the first time).  ICR_* and CUR_* (last para. 
p.17) should also be expanded, at first usage.

*ICR and CUR was changed during my editing at the AIW to full names.
Added explanatroy sentence on first usage of _ex and _cs.
Added forward reference to Section 3.5.

- section 3.3 (Correlators, p.15): this higher level discussion of the data
link correlator, port id, and transport id fields helped clear up some of
the confusion noted above, however some clarification in 3.2 still seems
in order.  Also, the (2nd para) statement that "the following rules must be
followed" isn't followed by any clear delineation (bullets or some sort of
list) of what rules you are talking about.  (Maybe reword that sentence to 
read: "However, for reliable interoperation across DLSw implementations, a
given implementation must adhere to the uses of the correlator fields with
respect to their assignment and fixing for each transport connection or 
circuit, as follows:")

* See new wording in version 0.15 and let me know what you
think.

Syntax: last sentence, 1st para in 3.3: "...should be echoed as is to partner
DLSw in subsequent messages." could read: "...should be echoed as is to the
partner switch, in subsequent messages."

*Reworded and broke up into two sentences.

- section 3.3 (Correlators, p.15): these section opens with the stmt that the
use of these fields is "an implementation choice" -- then (next para.) states
that their use must follow the listed guidelines "for correct interoperation."
It might be clearer to make the latter point in the first sentence (or not
make the "optional" statement at all, since *much* of this document is
optional in the sense that you don't need it unless interoperability is an
explicit goal ;-)

* See new wording in version 0.15, see what you think.

- section 3.5 (Message Type table): more syntactic moaning -- the "note"
callouts should be column aligned (and matching first char case -- it currently
reads like "Note 1" is higher precedence than "note 2") for clarity.

* Already changed the alignment while at the AIW.

- section 3.5 (last para, top p.19): another first-time-read observation (that
probably has little merit, but bear with me).  The NetBIOS message discussion
here includes the statement that NB DATAFRAME message types are one of the
five types sent in the control msg format ("For the exchange of NB control
messages,...").  Until this point (from the text at the top of page 10) I
was convinced that all information messages travel as part of the 
*information* message header format.  Contradiction?  If so, page 10 should
be qualified for "with the exception of [some] NB DATAFRAME messages...".

Will refer to Connect Group.

- section 4 (first para, top p.20): syntax nit -- "The initiator if the circuit"
should read "...initiator *of* the circuit".

*Already corrected at the AIW.

- section 4.2 (bottom, p.20): the annotation on the example would be a tad
clearer if the comment on the "read ack" read "the circuit initiator could
choose *either* valid value".  (The way it's worded, "any" value, implies
that the initiator can ignore both the original CANUREACH and the ICANREACH
reply, overriding the negotiation with an arbitrary value.

*Refer to Priority/COS Group.  (I think that that "any" was what Gene had intended,
I will send him Email and find out.)

- section 5 (State Machine, top p.21): second sentence references state
DISCONNECT; in the (5.1) state descriptions this state is called DISCONNECTED.
(The former form is then referenced again later.)

*Already did a global search and replace at the AIW.

- section 5.1 (first para): the statement about a separate fsm being employed
for each end-end circuit is fine, but the duplication of that statement on 
p.25 (DLC actions, last para) makes it sound like section 5.1 and 5.2 are
talking about two difference FSMs.  (Eliminate the latter stmt?)

* Had already fixed the first statment (there is only one state machine).
* Fixed 5.2 to be a single state machine (based on your comment, that
one had been missed)..

- FSMs, overall: I find that using the same name for (some of) DLC *actions*
and *events* is a bit confusing (I know, I know: talk to David Kushi ;-)

* Don't plan to touch this one, this is one we had discussed at the AIW
as far as how to clarify and that the terms were too "LAN" specific.
Consensus decision was to leave alone in order to expedite getting the
document out.

- section 5.2 (first para, first sentence, bottom p.23): syntax error: "...as
document by" should read "as documented by".

* Done

- section 6 (Protocol Flow, 1st para p.43): the 2nd/3rd sentence here is a
bit confusing, implying that LLC type 1 and 2 are used by the end stations
only *after* the DLSw circuit is in place (?).

* The key here is "end-to-end".  Added to type 1 description and explanatory
text.

- flows, general (p.49,p.51): I am surely missing something here, but it looks
from the diagram like we have a PU2.0 device (SDLC) incorrectly sending 
XIDs.  In the examples, it looks like the PU2 sends unsolicited NXID (doesn't 
it -- when configured as switched -- wait for a NXID from the primary station, 
and *then* send XID (type 0, NodeID) in response?)

* Will refer this issue to the Connect Group.

- flows, general (p.54 T2.1 example):  it may be worth stating that the T2.1
target station is configured as non-negotiable secondary SDLC, since it would
otherwise send unsolic. NXIDs immed. upon powerup (which complicates the
example prohibitively).  ALSO, in this example, you show the (T2.1) target
station receiving *SABME* -- since it's an SDLC device it should receive
SNRM/E from the primary (SABME is used w/ LLC2 ABM, not SDLC).

* Will refer to Connect Group

- section 7 (Capabilities, last para before section 7.1, p.57): the description
of GDS LT structured subfields is (I think) very slightly askew: it says the 
structured subfield includes the Type and the Data fields --- but not the
length (3rd sentence)..."so the length is n+2".  I don't have my FORMATS handy 
(I'm at home, and my 3-yr old can't find her copy either), but don't LT rules 
say the Length *and* Type comprise the (2-byte) header? Sorry, it's been a 
while...

* Will refer to capabilities group.

- section 8.1 (basic overview, flow control, p.68): I feel there's a little
ambiguity here around flow control of a DLSw *circuit* vs. that of the
switch-to-switch pipe (*connection*).  Maybe a concise definition of the
term "session" as used here (and in 8.6 et al) would be a good way of
making that clear, along with some stmt referring to "unique instances" of
the pacing machine(s) implemented for each connection/session.  The confusion 
is furthered by the fact that the initial window size in the CapEx is sent at 
connection establishment, but applies to all subsequent circuits (er, 
sessions)....(!).  (Legal to draw a parallel with adaptive/fixed session
level pacing in SNA, vs. T2.1 adaptive bind pacing?  I didn't think so...)

* Will refer to Flow Control Group.

I realize this is pretty high level, very nitty, and somewhat sketchy -- and I 
apologize that it comes so late in the game -- but better late than never 
(maybe ;-).

David McDonell
Networks Engineering
LKG1-3/A10
Digital Equipment Corp
550 King Street
Littleton, MA  01460

[email-masked]
508.486.7126

-- End Included (edited) message --